The present disclosure relates to the field of software change management, and more particularly to extending the software change management to uniformly handle artifacts which lack constraints typically imposed on managed items.
Teams of software developers can collaborate on a set of artifacts, typically referred to as “source code”. They can actively make changes to these artifacts regularly, sharing the changes with each other. Typically, software configuration management (SCM) systems can be utilized to manage these set of artifacts. These systems can help developers in many ways such as tracking the revision history of these artifacts, ensuring that developers have access to appropriate configurations of these artifacts, making developers aware of changes made by others on their team to other source artifacts, helping them obtain these changes in their work environment.
Developers can require access to externally managed artifacts that are not under their own active development. These artifacts can include third party libraries, binaries created by other development teams, companies, etc. These artifacts may be under configuration management in a separate SCM system having different rules and policies from the one the developers are using, which can be problematic. This situation often arises for team developed software where team members are employed by more than one company, each having their own standards. It is difficult and can be impractical to maintain synchronization between SCM databases and files used by the different companies. This can be problematic for all team members involved, especially when software builds even during development are generated from SCM managed items.
Additionally, some artifacts are not appropriate for management in the SCM system as their lifecycles, access rules, and management policies can be different from source code. As such, developers cannot take advantage of the SCM management features provided to developers for artifacts not under their own active development. Developers, however, need easy access to appropriate versions of these artifacts for the configuration of source code on which they are developing.
Often separate libraries and/or repositories can be maintained for these externally managed artifacts. However, there can be no easy way to know which version of these artifacts is appropriate for a given configuration of the source code. Further, developers need to be aware of this external system. Frequently the means for gathering externally managed artifacts into their work environment is distinct from the means for gathering their source code artifacts. The result is often confusion (classloading process problems, for example) about where to get the right versions, bugs in the software due to version mismatches, and reduced developer productivity.
Additionally, these artifacts can frequently need to be provisioned into specific locations in the developers' environments. Often, developers are not experts in the intricacies of the build process and the required locations of these other artifacts and as such are forced to perform manual provisioning. Manual provisioning can be a time-consuming and error-prone process which can negatively impact developer productivity. Thus it would be beneficial to alleviate the burden of manual provisioning enabling developers to be more efficient.